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with гу as ee 


What is the current stat 


of IS 


tly achieved a major milestone, the netting of all 
оп September 20, 1969. 


ISCS has just ree 
five computer site 


The system is built around Univac 418 processing and comi 
centers in San Francisco, Chicago, Atlanta, plus two sites in New York, 
The first New York si ation offering the service, TCI 
in January, 1968, INFO-COM was introduced in Chicago in Septem 
1968, The first netting was accomplished in May, 1969, with the 
of San Francisco and the second New York site, and their netting with 
the first New York site, The final site, Atlanta, was cutover and netted 
with New York and San Francisco on September 15, 1969. The final step 
was the netting of Chicago with the other sites on Septem! 
might add that all these steps were accomplished without disturbance 
to those subscribers of INFO-COM and TCCS already using the system 
and we are particularly proud that this fi 
опе month ahead of the schedul 


site network was achieved 
wromulgated in the Fall of 1968. 


You may be interested to know o 
and software performance 
next March 1970, At that 
sentially complete, 


we major package of hardware 
nhancements will be placed in operation 


What do you mean by the nett 


“N 
each ot 


ting” means that all computers are dir 
er through high-speed 2400 bits per second lines, This 
allows simultaneous transmission of large numbers of massages 
with rapid access to and from terminals anywhere in the country, 
all under direct and automatic computer control, 


This computer network allows us to offer higher capacity and 
proved service while minimizing our costs. It also gives us the 
ical and operational base for offering new and expanded 
services to our customers in the future. We envision in the future 
that а subscriber with one simple connection to one Western Union 
computer сап have access to а variety of services, automatically 
supplied and routed through this computer network, 
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The articles in this issue of the Technical Review are con- 
cerned with various aspects of system design and analysis. 
What is the significance of this type of activity at this rela- 
tively mature stage of the system? 


There is, of course, а continuing need in any system to evaluate actual 
operational performance and to compare this against the predicted 
performance of the initial design stage. In ISCS, this need is particularly 
pronounced, ISCS is a “shared” system—ive., it is 
many different Telex and INFO-COM subscribers. These sub 
come on the syste 
vidually, resulting in a steady traffic b 
of time. At present, no si more than 40% of capacity, with 
full load expected to be reached in late 1970. In contrast, a “dedicated” 
(single customer) system is normally loaded at initial cutover with its 
full population of terminals, and the initial traffic load can be close to 
design. capacity. 


опе at a time аз the service is sold to th 


dup over a fairly long period 
is handli 


The result is that there is no straightforward way to test a shared 
system at its full capacity in early stage 


f its Ше. It would be p 


hibitively expensive to implement a full terminal capacity for testing 


and creatis 
oped to obt 


purposes. Therefore, ext 
t be de 


simulation mi 


n experimental results from 


which valid conclusions can be drawn of system behavior at capacity 


operation. 


with its many individual 


Another important aspe 


of a shared syste 
users is the unpredictability of many of the fundamental usage para- 
meters upon which the syst 


n design must be based. This that 


in the initial design, some basic characteristics c 
only statistically, without much precision. N 


uld be predicted 
w with operational ex 


perience, we must determine the actual usage and compensate for it, if 


Av a simple example, a basic design param 


itching 
иет such as ISCS is the expected distribution of message lengths. 


Software structure, storage requirements and commu 


tion inter- 
facing are all partially dependent upon this parameter, as are through. 
т 

choose to send much longer messages on the average than were 
predicted in initial design. If so, either design changes must be made 


and capacity performance. Now, subscribers in actuality might 


to regain predicted performance, or the performance resulting from 
actual usage characteristics must be accepted. In either case, detailed 
analysis must be done to obtain the required knowledge. 


Since many of the parameters and interrelationships are qui 
ticated, the analyses must be extensive and sophisticated. 


sophis- 
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What is involved in doing such analysis? 


Generally, the process moves through theoretical analysis, verification 
by experimental data and analysis, and extrapolation of the results 10 
general conclusions which will be valid at capacity operation. The 
principal problem now is obtaining valid data for this verification and 
extrapolation, There are two sources of data, the operating system itself 
and the development laboratory. 


The actual operating system obviously yields true, real-world data 
and this is extensively used for analysis. Numerous statistics are auto- 
‘matically generated and are available at periodic intervals or upon 
request. This allows quick construction of time profiles of total traffic, 
intercept load, queue sizes and the like. We have computer programs 
available to obtain more sophisticated data—the daily system journals 
(records) are run through these analysis programs to yield information 


on message types, speed of service, message lengths, and the like. 
Finally, the old-fashioned method of poring over pieces of paper, such 
as message copy, is still the best and/or only way for some problems, 
such as obtaining a detailed understanding of customer input errors 
The operating system yields data only at current traffic levels. The 
real challenge is to obtain data valid for prediction of capaci 
performance, and th vere the development laboratory comes in. 
This laboratory can be configured to simulate а 
network, plus а reasonable sample of all types of 


site or а partial 
bscriber terminals. 
mate for any of our 


It also provides computer proce 
engineering analyses or simulations. 


к power adi 


We have developed and programmed powerful simulators which 
allow us, totally within the lab, to simulat 


capacity traffic environ- 
ment. Real input from numerous actual terminals can be combined 
with this simulation to give a high degree of flexibility in analysis of 
various types of traffic, messages. errors, etc. Computers next to each 
other in the laboratory can be connected by high speed lines which loop 
to San Francisco and back, if desired for analysis of coast-to-coast net- 


work operation. In addition to performance analysis, these simulators 
are principal tools in the debugging and testing of new software in a 
high trafic environment, and for the recreation and solution of 
operational problems. They are also valuable operational training aids. 


The articles in this issue discuss examples of the various analyses and 
simulations by which, using the development laboratory and operational 
data, capacity performance of the system is predicted. 
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And what about SICOM? 


The SICOM (Securities Industry COMmunication) system is the 
company's other operational shared system. As you know, it offers а 
service similar to Info-COM, but specialized for the needs of the stock 
brokerage industry—transmittal of securities orders, executions, and, 
related traffic between brokers’ branch offices and the floor of the 
stock exchanges. 


SICOM was cutover into operation in June, 1968, and has been very 
successful. This computer system has consistently exhibited good per- 
formance, speed and reliability. Design and development work are 
complete, and SICOM is already а mature system. With its good re- 
ception, capacity additions will be required next year. 


What is the significance to Western Union of the activity 
you have described? 


First, technology and economics dictate that the computer must 
be an essential element in the transfer, control and processing of 
formation as we move into the future. Information transfer is of course 
Western Union's main business, so expertise in computer technology 
and operation or more precisely, computerized communication tech- 
nology and operation—will grow increasingly more important to the 
company. 


Second, this large-scale shared system approach in а commercial 
environment is breaking new ground, as did AUTODIN and the Ad- 
vanced Record System in the government sector, and the various 
private commercial systems implemented by the Company. Western 
Union need take а back seat to mo one in this computerized com- 
munication technology. 


The combination of this importance with corresponding leadership/ 
competence is encouraging for the future. The Company has а good 
start toward the systems and services of the 1970's 
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MEASUREMENT 


OF ISCS THRUPUT 


Thruput, broadly stated, is a measure of the pri- 
тагу performance of a message switching system: 
it is a measure of the number of transactions 
which can be handled per unit time by the system 
This number is dependent upon the processing 
time required per transaction, upon the in-process 
storage requirements, and upon the input /output 
channel utilization and the message (bulk) storage 
requirements. Over much of the system's normal 
‘operating region, thruput is roughly independent 
of message delay. An optimized system will attain 
its maximum thruput when, under conditions which 
cause its limits to be invoked, all limits are 
reached simultaneously at some pre-specified mes- 
sage delay time. System specifications usually 
include allowable delay and thereby set the maxi 
mum level of system activity or гири 
Recently, ISCS was tested for performance and 
thruput margins were established. The process 
involves testing to as high a level as possible, 
observing the limit and then establishing whether 
this limit is structural or allotmental in nature. A 
structural limit is time related and, as such, re. 
quires recoding, new coding, or faster hardware. 
Such limits would consist of the available proc 
essing time per message resulting from 1/0 and 
CPU utilizations, or on instruction sensitive table 
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sizes. An allotmental limit is storage capacity re- 
lated and is defined as one where only expansion 
is needed. Examples of the latter category include: 
the number of active lines that are specified to be 
possible at any one point in time, the amount of 
storage set aside for in-ransit message process 
ing, etc. Usually, the allotmental limits are first 
observed and when they are isolated, they are 
expanded and the process repeated until the struc 
tural limit is reached. In the process of establish 
ing the thruput margin many system sensitivities 
are recovered and the formulation of the system 
model accomplished. 

The demonstration of thruput margin provides 
in a sense a somewhat optimistic view of the sys: 
tem's expected behavior under volume. During 
this demonstration, the multi-varied service re 
quests and error conditions which normally occur 
in an operational environment are held at a mini- 
mum in order to permit system time to be used 
most efficiently for message processing. The addi 
tional requirements of message assurance, mes. 
sage liability, service and functional requirements, 
and system stability are necessary ingredients for 
‘establishing system acceptance, but are not of 
interest herein except insofar as these attributes 
concern the demonstration of thruput margin. 
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For the ISCS system, the performance measure 
of thruput was taken as its optimized or maximum 
capability defined in terms of a long time average 
traffic handling capacity without significant mes- 
sage backup within the system. Mathematically, 
the ISCS measure of thruput may be presented as: 


Aan = 


where озы he = Lh 


This definition was chosen in order to satisfy the 
peak hour traffic requirements of the ISCS system. 
In a system as complicated as ISCS, thruput margin 
is a function of many influencing factors including 
traffic characteristics and the time history of traffic 
characteristics. The three main limitations to sys- 
tem thruput include the maximum possible Central 
Processing Unit (CPU) utilization, limits of in 
process and in-transit storage area, and the input/ 
output (1/0) channel utilizations. All of these are 
effected differently by the different classes of serv. 
ice incident upon this system and by the traffic 
characteristics of these services. In this design of 
demonstration tests it was adequate to linearize 
the system's complexity, since for the accuracies 
desired a linear approximation was sufficient when 
considered locally; and any further refinements 
because of the complexity of the system would be 
uneconomical. It is therefore necessary to be quite 
careful to apply these linear approximations only 
‘over dynamic ranges where they can be considered 
to hold. 


ISCS Functional Overview 


In the design of a good thruput test, the ele- 
‘ments which would restrict thruput first have to 
be identified. For this reason, a test model was 
developed which separated these system sensi 
tivities into nearly orthogonal components and 
then the tests designed to measure these sensi 
tivities. This in effect created a surface of thruput 
margin of many dimensions as a function of the 
many components of the environment and system 
limitations. 

Test model development requires an under. 
standing of the ISCS system functions and their 
implementations. The ISCS system is a message 
switch—concerned with accepting and delivering 
messages. It consists of two functional and physi- 
cal entities; a Communications Center (CC) and a 
Processing Center (PC). As the name implies, the 
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CC acts as a line processor and concentrating ele- 
ment where data entering on low speed lines, 
character by character, is analyzed for format, 
blocked, and shipped to the PC via an intercom- 
puter coupler for processing. A CC element in a 
network also does primitive routing of the message 
in order to present it to the proper PC. The PC 
functionally consists of queue facilities to process 
the messages. It interrogates the various aspects 
of the message address for errors or destination, 
performs privacy and validation checks, routes 
and queues for output, and outputs to the destina. 
tion CC once a line to the address has been seized. 

ISCS currently services, on input, two types of 
customers; Telex subscribers, who may dial up the 
CC, and directly-connected INFO-COM subscribers, 
An INFOCOM subscriber has a set of terminals 
with coded answerback drums called an INFO-COM 
network. Thus, for an INFO-COM subscriber, ISCS 
is a private message switch utilizing a shared 
store-and-forward system. In addition, both INFO- 
COM subscribers and Telex subscribers can send 
messages via ISCS to Telex, TWX, and TMS (Tele: 
gram Message Service). Here, is the first part of 
definitizing the traffic environment. 


Tout ics 

»owTx rin of mp f à out rix 

Aino! mame Your TWX те A Out TWX 

Subscribers [Out TMS — subscribers | Out TMS 
Where 16 = INFOCOM Service 


TMS = Telegram Service 
-> = allowable delivery path 
) eut = output message rate 


Another aspect of the traffic environment is the 
multiple address (MA) input message (many ad. 
dresses for one text message) and for INFOCOM 
the Group Code message (one input message 
which keys to many prestored addresses). These 
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two services result mainly in generating more de- 
liveries than input messages; and in addition MA 
messages have a tendency to increase the mean 
message length on input, because of the additional 
addresses. 

Another message environment parameter which 
will effect thruput is the message length. Both CC 
and PC require the moving of data either within 
or through core. This will require both an in 
process storage level and code to be executed for 
this function and on output, queues need to be 
scanned to find a deliverable message. 

Hardware for the system consists of the termi- 
nals and lines, two UNIVAC 418 computers, one 
containing the CC functions, the other containing 
the PC functions, an Intercomputer Coupler (ICC) 
connecting the PC and the CC and peripheral 


class of service and character rate. 

‘Armed with this understanding of the functions 
of both the PC and the CC and investigating the 
implementation of these functions, we can pro- 
ceed to the development of the test models. 


Test Моде! 


The CC functions, as implemented, basically 
consist of low speed line servicing, high-speed 
line processing, and task queue processing. Low 
speed line servicing is initiated periodically, 
roughly a little faster than the input or output 
character rate. As the characters are received, 
they are blocked and placed on the task queue 
for processing; on output the blocks are emptied 
‘one character at a time. When the low-speed proc: 


Figure 1—A Typical ISCS Site 


equipment on the PC 1/0 channels for maintaining 
routing files and for storage. The peripheral set 
consists of a Fastrand Drum, 330 Drum and Tape 
units. 

The Fastrand is a mass storage drum which 
contains primarily the message data while waiting 
for delivery. It also contains the necessary jour. 
nals, some recovery information, overflows of 330 
storage areas and routing tables. The 330 drum 
is much less massive but faster and is used pri- 
marily for storage of data which is more frequently 
used in the processing of a message such as mes 
sage control packet and message queues. The 
tapes are used for permanent records and contain 
all system journals. 

Thus, we find that the PC behavior is governed 
by the input and output traffic rate, the type of 
service, the message length and the queue sta 
tistics; while the CC in effect is dependent on 
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essor is allowed to run it removes an item off the 
task queue, processes it according to its contents 
and if it is an input block, schedules it for high 
speed out to the РС; if it is an output block, it is 
placed on an output queue for low speed line 
processing. The CC is mainly character rate de- 
pendent and its capacity measured by the con 
tents of the task queue ог the wait time statistics 
of the task queue elements. Thus, a characteri 
zation of the CC as to its thruput would be the 
relationship between task queue wait time and 
character rate. The character rate taken within the 
expected environment will then define the line 
handling and terminating capability of a CC. 

As a result of the character sequence detecting 
for TCCS message format and the implementation 
of this as opposed to single character detection 
for formats of INFOCOM messages, the task queue 
processing for these two services is significantly 


WESTERN UNION TECHNICAL REVIEW 


different. INFOCOM processing time per message 
in the СС is considerably less than that for TCCS 
and thus in considering CC performance under 
volume averages, task queue wait times need to be 
observed under each type traffic separately and 
then at various traffic mixes. The functional re- 
lationship between the task queue wait time and 
traffic can then be determined and used to predict 
performance of any specified traffic and mix. An 
upper limit to CC thruput is defined by the CC 
structure which is such that, on input, characters 
transferred to a circular buffer have to be emptied 
faster than it is filled. These buffers are seg- 
mented into five processing blocks. When one 
processing block is filled it is scheduled for proc- 
essing via the task queue where it waits for 
service. In the mean time the other segments of 
the buffer are being filled at line speed. 

The buffer is entered via a Low Speed Line 
Service (LSLS) pointer for insertion of characters. 
When this pointer encounters the last word of this 
buffer, it initializes to the top of the buffer. The 
characters are analyzed by low speed processing 
(LSP), keying into the buffer by the LSP pointer. 
Overlap is observed when the LSLS pointer catches 
the LSP pointer. The upper limit thruput margin of 
the CC is therefore determined by observing, un- 
der a given environment (message length and 
traffic by class of service), the traffic when the 
task queue wait time consistently indicates over- 
lap in the circular buffer. This overlap has the 
effect of potentially dropping characters. When 
the overlap is detected by the CC, the connection 
оп which it occurs is dropped, thus degrading 
service to the customer. 

The PC test model is more application oriented; 
by this it is meant that as different aspects of the 
messages are analyzed and as new functions are 
required, they are scheduled to be performed. 
These scheduled functions are then performed on 
a particular message within a PC priority structure. 
established by the Executive system. When the 
PC has no work to do, it sits in an idle loop which 
will accumulate idle time. 

Functionally we represent the PC CPU utiliza- 
tion (p) test model as; 


в = 1,9,9) (2) 


That is, we establish that р is dependent i 
way on three parameters: 
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input and output processing of messages (A), on 
the moving of data characters for input, output, 
and journalling functions (4), and on the need to 
scan and find available queue entries to initiate 
output (Q). From an understanding of the PC 
functions previously described and their imple- 
mentation, the functional expression takes the 
following linear form: 


p = 45+ Атха + Ast Mes 
+ Aa Asstatintorts + Аз" Ма" fin 
+ BiQnix + BiQies  BiQris 
+ Ci Amxeu + Cet Acson + Са arit 
C Aout” Pour 
+ D> Vues Ese t 


(3) 


The As, Qs are respectively the traffic and те: 
sage queues established by the environment and 
indexed by the class of service. W is the mean 
message length and is required to obtain cha 
acter sensitive performance. Here TLX and TWX 
processing is so similar that we equate TLX to 
TLX plus TWX. These parameters act as dependent 
variables in PC utilization models. The As, Bs, 
Cs, etc., are the various sensitivity coefficients 
identified in the model whose recovery is required 
for the test objective. A, is a bias coefficient and 
is obtained under conditions where traffic and 
queues are zero. It is the overhead work accom- 
plished when there is no message processing to 
do. A, and A, are the sensitivities to the different 
types of input; TLX and INFO-COM. Since TMS des- 
tined message routing requires state and city 
searching in addition to privacy checks and val 
dation implied in A, or А, these messages have 
additional processing on the input side. This 
sensitivity is defined as As. A, is the character 
rate sensitivity on the input side. By, By, and B, 
are the queue size sensitivity coefficient for the 
TLX, INFO-COM and TMS services respectively; Cı, 
С» and C, are the output work for the same serv. 
ices. C, is another character sensitivity but on the 
output side. D, E, etc., are undefined coefficients 
related to types of input and output error condi 
tions as well as infrequently used services avail- 
able such as alternate routing terminals and 
group codes in INFO-COM end amended header 
processing at an intercept position for TLX. 
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Test Objectives and Results 

These test models make it possible to translate 
economic objectives of revenue producing traffic 
into performance test objectives. These test ob- 
jectives and the results of testing fall into four 
тат categories: Thruput Margin, In-Process Stor- 
age Limit, Recovery of PC Sensitivity Coefficients 
and the CC Task Queue Wait-Time Function. 


Thruput Margin. 


The first and probably the most significant, 
from a thruput margin sense, is the measuring of 
the uppermost bound of PC CPU utilization; 
the maximum depth of penetration into the idle 
time at which the system remains operationally 
stable. In actuality, since there is always some 
amount of 1/0 channel functions that have to be 
with CPU there will always be an upper 
bound of CPU utilization that is less than 100 
percent. This objective will, of course, be attainable 
Only if ай other system allotmental limits are 
avoided. This structural limit will be established if 
the system runs out of channel time or CPU time. 
The maximum CPU utilization so far attainable for 
any sustained period of time is approximately 70 


Percent. Figure 2 is a parametric plot from data 


obtained during testing of CPU utili 
function of thruput for the test environment of 
100 percent INFOCOM, an exponentially distrib- 
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uted message length variate at various mean 
message lengths, and the mean output rate 
within 10 percent of the mean input rate. The 
gathering of data samples for establishing this 
relationship consisted of running tests at various 
levels of thruput under the standard test environ- 
ment and taking long term averages. The time 
histories of traffic and CPU utilizations is the first 
level of reduction. From these graphs, sample 
points are determined by segmenting the curve 
into intervals of at least 5 minutes long and 
usually not longer than 20 minutes at times 
where transient conditions or changes in traffic 
level were not observed. The CPU utilization over 
this interval is then plotted against the thruput 
for the same interval to obtain the parametric 
relationship. Once sufficient sample points are 
obtained which span the range of thruput they 
are fitted to a linear curve in the sense least 
squares (ie. the sum of the squares of the 
sample points from some curve is minimized by 
adjusting the curve). 

Figure 3 depicts the input and output traffic 
rates and CPU utilization time histories taken 
Over 1 minute samples for both 300 and 600 
character messages. During both test runs the 
long term averages of input and output rates are 
mearly equal, thus yielding sample points for 
parametric relationships. Two events are noted 
оп the graph; а) the IOSERR table limit is an 
example of an allotmental limit which was over: 
come by expanding this table, whereas b) the slot 
table limit being instruction sensitive it exhibited 
а structural limit. The reaction of the system after 
these limits were encountered is peculiar to the 
individual limit and not necessarily to the type of 
limit. 

At the maximum CPU utilization (the thruput 
margin point) any attempt to force more traffic 
through the system will cause a departure of the. 
output traffic from the input traffic. Generally, 
input has priority and as long as no limits are 
invoked, the system will accept input even when 
it does not have any processing time left to handle 
output. Thus, as the input increases above satura- 
tion, the output will decrease. This will have the 
effect of building queues at a rapid rate and as 
such remove even more processing time from 
output. If we were to project this effect and allow 
the definition of thruput to become nonlinearized, 
the curve, of Figure 2 would tend to turn around 
оп itself (in effect decreasing thruput). 
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Figure 3—Time Histories of PC CPU Utilization (a), Input Rates (b) and Output Rates (c) 
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In-Process Storage Limit 


Next in significance is the determination of the 
CC and PC in-process storage statistics under 
varying environmental conditions. The in-process 
storage current contents will exhibit the charac- 
teristics of a random variable because of two basic 
conditions, First is the fact that the environment 
is random in nature; i.e., the arrival times of new 
messages is a Poisson distributed random varia- 
able and message lengths are distributed ex- 
ponentially. Secondly, because of the use of files 
and data on random access mass storage devices 
‘and because of contention for these devices аз 
well as contention of programs for CPU (since 
many messages may be in some state of process- 
ing at the same time), the service time of a mes- 
sage is also random with a not so easily described 
characteristic. These two facts (when viewing а 
simple queue model) will cause the in-process 
storage contents to be distributed. By sampling 
periodically the current contents of the in-process 
storage and maintaining constant mean traffic, a 
frequency distribution of the number of occur- 
rences of a level of usage of the storage will 
characterize this performance parameter. From 
this data a statistical model evolves which will be 
used for predicting behavior under untested en- 
vironments. Calculating the mean and standard 
deviation of the data at various levels of traffic 
and message size and assuming it is a normally 
distributed variate we can size this storage given 
a certain message rejection criteria. The message 
rejection criteria can be translated (with known 
message size) into a probability statement of a 
block finding the storage full since a connection 
is dropped if one or more of its blocks finds the 
in-process storage full. 


Letting РС) = probability of (©) 
P (dropping а connection — 1 — P not dropping a connection) 
P (not dropping a connection) = P (not dropping the 1st bik 


Since the probability of dropping any one block 
of a message is assumed equally likely— 


P(not dropping a connection) 
= P(not dropping one Моск)" 
= 1— nP (dropping one block) a 
Where n = average number blocks in a message 
With this, we now can specify in a statistical sense 
a P (dropping a block) and by applying this to a 


am 


normal distribution we define the number (N) of 
standard deviations from the mean required. The 
required size of the Block Storage Pool is then 


If we require a size for an untested environment 
the sizing will have to be expressed parametrically 
with the thruput (A) message length (ф) and М. 


Figure 4 is a typical histogram of the PC's 
in-process storage (Block Storage Pool or BSP). 


* 
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Figure 4—FC Block Storage Pool Histogram 


Under a steady state condition the BSP was 
‘sampled as to its current contents and the number 


P (eot dropping the 2nd ык... . Р (not dropping the nth ЫЮ 
of occurrences of each interval recorded. From 
this we establish a mean value and standard devi- 
ation of the density function it represents which 
we use for sizing. 

In developing a parametric relationship of a 
BSP size and the independent variables of traffic, 
message length and a rejection criteria three 
observations of the data were made. These were: 

1) The mean BSP value was linear with respect 

to variation in message length while traffic. 
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was held constant 

2) The mean BSP value was linear with respect 
Хо variations in traffic rate while message 
length was held constant 

3) And finally that the standard deviation was 
consistently close to twice the square root 
of the mean BSP independent of the traffic 
or message length. 


With these observations and by taking partials 
of the mean BSP function first with respect to 
traffic and second with respect to message length, 
the following BSP sizing model was developed: 


Ум) = WA+2NVE pA (5) 


where YO N) = BSP Size 
k = 1/3, a constant of proportionality 
Ж = mean message length 
A = mean thruput 
N= 


rejection criteria 


Applying these sizing equations with N equal 
to 3 and 4, the curves of Figure 5 are generated. 
Fig. 5 illustrates the size required for the BSP, 
as a function of traffic. At М = 3, we would expect 
to drop 3 messages out of every 100; where ot 


yr 


Figure 5—PC Block Storage Pool Average Contents vs 
Mean Message Length at Given Traffic Levels 
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М —4 we would expect to drop less than one 
300 character message out of every 1000. 

This analysis concentrated on the PC BSP, 
since this was one of the first allotmental limits 
reached. Although the CC in-process storage 
statistics indicate a usage greater then the PC 
BSP there are many more blocks available in the 
СС. The same analysis of the CC in-process storage 
would apply except that observations and eventual 
assumptions made for the PC BSP may take on 
different forms. 


RECOVERY OF SENSITIVITY COEFFICIENTS 


The third objective is the recovery of the co- 
efficients of the PC test model. This is accom- 
plished by establishing a baseline level of traffic 
near the thruput margin and varying one de: 
pendent parameter at a time. Since these para 
meters are essentially orthogonal the variation 
of one should not significantly effect any other. 
The relationships are not always linear over the 
system's total operating range. However, they do 
exhibit a local linearity and because we are in- 
terested in system capacity, these sensitivities co- 
efficients are measured near the thruput margin. 

Since the system only requires that output 
traffic follow closely to input traffic, which also 
will result in low queues, the PC CPU model was 
reduced by combining input and output traffic 
of like service. Thus— 


p = А» + Алихан + Асат 
+ Ачыты + Ахон + cesar) 
(6) 


Solving for the coefficients we identify partials 
and then take the related differences to obtain 
the coefficients. 


А, is obtained by noting the value of at the 
intersection of the curve of Figure 2 with the ordi 
nate at zero traffic. As observed А, equals .085. 

In order to obtain А, and A, it is easier first of 
all to obtain A, the message length sensitivity. 
The uncovering of A, is done by averaging the 
series of partials obtained at each traffic level 
investigated. Thus, by observing the average nor- 
malized slope of the curves of Figure 6, we obtain 
‘Ac in terms of utilization in percent per (msg/sec 
X char/msg). 


Therefore, 
D 
4 = Gata - 449 ay 
and A qi A. a2 


А, is solved for in the same manner as Ay, 


For a finer analysis of PC performance more 
tests can be run where the other identified 
sensitivities such as those related to queue size, 


error traffic, and class of service can be separated 
and the model expanded to incorporate these 
sensitivities, 

CC Task Queue Wait-Time Function 


The last objective is the establishing of the 
task queue wait time function. This in effect 
would establish the CC thruput margin related 
to CPU work load as opposed to in-process 
storage limits. We obtain this function by monitor- 
ing the current number of active connections both 
input and output under a specified environment 
or a particular character rate and observing the 
task queue waiting times. By obtaining many such 
samples at a fixed environment we plot the aver- 
ages against the thruput rate of a particular 
message size. The CC thruput, in this sense, is 
that thruput rate where we just exceed the maxi- 
mum allowable task queue wait time, which is 
about 5 seconds. This function, though seem- 
ingly straight forward, is complicated by the 


174 


== 


Figure 6—PC Block Storage Pool Average Contents vs 
‘Traffic at Given Mean Message Sizes 


fact that a collocated CC, which is terminating 
high speed lines from remote CCs in a network, 
places these blocks on its task queue for proc: 
essing before shipping it on to the PC. Figures 
7 and 8 on pgs. 174 and 175 are time histories of 
task queue and connection data for a remote and 
collocated CC in a network respectively. Both CCs 
are processing low speed traffic that is equivalent. 
The collocated CC is also handling the remote CC's 
traffic for shipment to the PC. We note that the 
averages differ slightly, but the variations and the 
means of the maximum contents is many times 
greater in the collocated CC as opposed to the 
remote CC. 

The task queue wait time is a highly non-linear 
function of traffic which follows the characteristic. 
queueing/utilization shape. This is observed in 
Figure 9 which defines the task queue wait time 
function for both classes of service; INFO-COM 
and Telex. The critical thruput rate for TCCS is 
shown in the data for a 300 character message 
and was easily obtainable, but PC limits were 
invoked in the all INFO-COM environment before 
CC task queue wait time reached criticality. This 
difference is due to the different processing ap- 
proach taken in ТСС from INFO-COM as men- 
tioned earlier. 
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Figure 9—CC Task Queue Wait Time vs Thruput 


Test Support 


Throughout this article the terms "maintaining 
the environment", "fixed traffic level", and “long 
term averages in steady state conditions" have 
been mentioned. Indeed, in order to establish 
some mathematical relationship between two 
parameters, environments have to be maintained, 
зо that the statistical parameters may be time 
invariant. This controlled environment for per- 
formance testing is quite necessary. If a test 
to be performed requires a sequence of events, 
to be acted upon at prescribed times, these 
events have to be coordinated. If a test is run. 
for instance, where message length sensitivity 
is being measured, at some time in the test it 
would be desirable to either change the message 
length while maintaining all other stimuli constant. 
or to rerun the previous test with only this change 
in the environment. A controlled traffic environ 
ment is rather difficult to maintain where manned 
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terminals are supplying this environment, espe 
cially if the input terminals are physically separate 
and are geographically located some distance from 
the computer sites. 

To avoid this coordination problem and to gain 
an easily adjustable controlled environment, a 
software diagnostic called TPUT, was used for 
performing tests. TPUT is a CC machine resident 
routine, which obtains control from the line scan- 
ning functions and services the line input and 
output butters simulating terminals, It maintains 
its own tables and as such has as little interference 
in regular CC operation as conceived possible. It 
does effect CC running time and consumes buffers, 
but it maintains timing statistics on itself which 
сап be used to update CC data. The TPUT user 
has complete control of the environment when he 
specifies the type of input service, the destination 
mix, the message length function and traffic by 
the number of active lines. In these tests, the en- 
vironment was specified first to match expected 
environment and then modified to separate the 
various message sensitivity coefficients and gather 
statistics on the in-process storage limits. 

TPUT, which requires ultimately one operator 
to perform a specified volume test, was particu- 
larly efficient in testing the performance of ISCS. 
The efficiency of testing (useful data per unit 
time of testing) was very high. 

Another important facet of test support is the. 
recovery and reduction of system data. In order 
to know the task queue wait time or the PC 
utilization it first has to be measured and then 
presented externally. The ISCS system maintains. 
and gathers its own status and periodically (over 
minute intervals) snaps the data on a high speed 
printer. In the CC, the data consists of items. 
Such as: the number of current lines active on 
input and output, minimum and current available 
in-process storage buffers, and the maximum over 
the interval and average over the interval of the 
task queue wait times. In the PC the accumulated 
number of input and output messages, peripheral 
accesses, idle time, blocks transmitted to and from. 
the CC, current status of the contents in the sys- 
tems queues, and in-process storage availability 
are monitored. 

In addition, the PC provides an option of also 
gathering the data on tape. Thus, for the PC 
data off-line data reduction routines were designed 
and implemented to present the system raw data 
in engineering terms ready for analysis. 
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Test Results Overview 


Now that the system is fairly well understood 
both functionally and from the point of view 
of performance and the primary elements of data 
reduction and analysis are behind us, it would 
appear to be desirable to recap some of the 
ISCS revelations in a more or less time ordered 
sequence as they were experienced during testing. 
Some of the allotmental limits which were over 
come by relocation or expansion not specifically 
mentioned previously are the following: 


1) A TCCS CC Character Processing Limit was 
first encountered and found to be structural 
in nature. A structural redesign would solve 
this problem if required. 


2) A PC BSP Limit was identified. This limit 
was overcome by expanding the BSP into 
core areas where service functions not used 
in testing normally reside. 
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3) A PC Input Siot Limit was encountered. A 
slot is a data link between the CC and PC. 
The input slots were expanded to a struc: 
tural limit. 

4) A PC output table limit was encountered 
This table was relocated and expanded. 

5) Finally, the system thruput margin (PC CPU 
structural limit) was defined and recognized 
as the inability to further overlap CPU and 
1/0 time and/or inability to further increase 
slots and slot related tables. 


These "discoveries" and their subsequent cir. 
cumvention were of some aid in the design of 
software enhancements. Since ISCS is typical of 
а major real-time software development program, 
this type of testing technique employed to up. 
grade performance efficiency and the subsequent 
data analysis which followed are of interest and 
can be invaluable to designers of systems similar 
to ISCS. 


formance Requirements, Design and 
‘Analysis in the Systems Design and 
Analysis Group, of PLEO. 

He is currently responsible for d. 
fining and monitoring system per- 
formance of ISCS 1 and for aiding 
in the design of ISCS II by develop. 
ing system models, simulations and 
tests. 
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degree in Electrical Engineering 
from Villanova University in 1959. 
He is currently attending New York 
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‘graduate studies in Operations 
Research and Computer Sciences, 
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SICOM EXHIBIT 


| has live 


Demonstration 


at ASEF 


The Securities Industry Communi: 

cations system was demonstrated live for aver 1500 

members of the Association of Stock Exchange Firms, at the New 

York Hilton, N.Y.C. on September 3 thru September 5, 1969. 

The exhibit was designed to show the flow of information through SICOM's three work areas: the 

stock exchange, the brokerage firm's wire room and the local brokerage office. Viewing the exhibit were senior 

management partners and operations personnel as well as communications managers who sought further infor. 

mation and literature on the system. Printed brochures and reprints of the article which appeared in the Summer 

1969 issue of the TECHNICAL REVIEW, entitled, “Shields & Company—The First Customer on Wall Street to Cut. 

Over to SICOM" were picked up quickly. 

The major application of the simulator has been in the analysis and evaluation of Western Union's SICOM 

system. It will serve as a valuable tool in the performance analysis of future applications such as Order Match 
ing, which is to be integrated into the SICOM system. 
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A SIMULATOR 
FOR 


EVALUATION OF A SHARED 
COMMUNICATIONS SYSTEM 


А simulator was designed by Western Union 
for use with a shared communications system 
for multiple subscribers. A shared system has 
an inherent volume testing problem in that 
traffic buildup is on an incremental basis as new 
subscribers are added. Consequently the full ca 
pacity of the system is not realized for a long 
period of time. Therefore, unless a very large 
network is available for volume testing, system 
performance at full capacity cannot be evaluated 
until full capacity is actually achieved. To over- 
come this problem a simulation program, which 
сап provide maximum loading under various test 
conditions, has been developed. 

The basic hardware configuration to which the 
simulator is applied consists of two Univac 418 И 
computers connected by an Intercomputer Syn: 
chronizer (ICS). One 418 computer, designated as 
the Front End (FE), acts as an interface between 
the message switch and the communication lines. 
The other 418, designated as the Message Pro- 
cessor (MP), acts as the basic message switch— 
receiving messages from the FE, performing ana- 
lysis on them, and routing them through the FE 
to their proper destination. The simulator is part 
of the FE; it actually has two functions, 1) it 
completely replaces the Front End programs, 
and, 2) it is integrated with the Message Proc: 
essor to perform data capturing functions for 
volume te: 
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by C. FREY 


Front End Simulator 


The FE simulator, located in the FE computer, 
completely replaces the normal on-line programs. 
Its basic function is to generate messages at a 
controlled rate and according to a predetermined 
Active Test Pattern. These messages are sent 
across the ICS to the MP, which processes them 
as it would during normal on-line operation and 
sends them back to the FE, The FE throws the 
returned message away and sends an End of 
Message (EOM) to the MP after a ten second 


ten second wait simulates a good trans- 
mission to an ASR set of an eighty (80) character 
message. This is the average length of mes: 
sage handled during on-line operation. 


Message Types 


The FE simulator is designed to generate two 
basic message types. The first is a Formatted 
Text Message which is very strictly validated for 
line length and specific field content by the Mes. 
sage Processor. The second type is an Administra 
tive Message which is validated only for proper 
header format and message length by the Mes- 
Sage Processor. Both message types are thirty 
(30) characters long. Either message type may 
be routed to single or multiple destinations or 
addresses. 
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Test Patterns. 


Two types of test patterns have been developed: 
active and non-active, 


a) Active 


The messages are generated according to an 
Active Test Pattern, created from the computer 
console at the initiation of the simulator run. 
Once this test pattern is created, it remains con- 
stant and is repeated in cycles throughout the 
duration of the test. The messages are generated 
at a controlled rate, but this rate may be changed 
at any time during the test by a console entry. 
This rate may vary from one message per second 
to a maximum of fifteen messages per second. 


b) Non-Active 


The simulator also contains eleven core Non- 
Active Test Patterns which are inserted at 
sembly time, These Non-Active Test Patterns are 
combined by console entries at the beginning of 
the simulator run to produce the Active Test Pat- 
tern. These Non-Active Test Patterns contain one 
word for each message to be generated by the 
pattern. The words in memory have the format 
shown in Fig 1. 


کے و — 


BIT NUMBERS | 
7 15 14 98 65 0 
MESSAGE | SUBSCRIBER] STATION 
TYPE | NUMBER NUMBER 
A B с 
meto a 


Indicates any one of the following four message types: 
MütiAdóress Formatted Tert 


Singlesddress Administrative 
Single Adress Formatted Text 


Contains a Subscriber Number. This field is not specified until 
‘he Active Test Pattern a generated, 


парс | 
‘Contains а Station Number. 


Figure 1—World Format for a Non-Active Test Patter 
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The following Non-Active Test Patterns exist 
in the simulator: 


POOl 0400001 
0100002 
0300003 
0200004 
0000000 End of Pattern 

POO2 0300005 SA Administrative Station 5 
0300006 SA Administrative Station 6 
0300007 SA Administrative Station 7 
0300010 SA Administrative Station 8 
0000000 End of Pattern 

РООЗ 0400011 SA Formatted Text Station 9 
0200012 MA Formatted Text Station 10 
0000000 End of Pattern 


MA Multiple два 
"SA Sine Address 

It can be seen from the above illustration that 
Non-Active Pattern one, POOL, has the capacity 
or producing four messages, as does Pattern 
two, POO2. Pattern three, P003 however, can 
produce only two messages. It must be remem- 
bered that they can produce no messages unless. 
they are chosen as part of the Active Test Pattern. 


How an Active Test Pattern is Generated 


At the start of a simulator run, the Non-Active 
Test Patterns are combined to form an Active 
Test Pattern via a series of console entries. This 
generation takes place in the following 8 steps: 


1. Program Request 
2. User Response 


ENTER SUBSCRIBER. 
Number trom 120 indicating which sub- 
Serer” ito Бе associated" with the 
{Sowing patterns), or АМИ эй sub 
Жыз. i ALL, program proceeds to 
E 

Next 

The next subscriber number to be эк 
Date with wee folowing patterns, 
S END i no more subscriber number 
re to be entered: И а number e entered, 
{he program wi return to sep 2. If EN 
is entered, the program will proceed to 
eps 

ENTER DESTINATIONS 

The three digit number of a Nondetive 
Tes Paterno satiate min, the 
‘This number must be proceeded by з 
Por example: Foi. 

Next 

The next test pattem to be associated 
ity e Drevigusly entered. subscriber 
ботын, б END и по more pattem 
umbers are to be entered, 1 a pattern 
umber is entered, ‘program will return 
То step 7. WENO is entered, the program 
PU etm to step 1 for a new group 
Sr subscriber numbers. THis process cot 
Enies unti an answer of STE i received 
i alen L When STP is entered, the 
Reve Test Pattern Te complete. 


2. Program Request 
4. User Response 


5. Program Request 
© User Response 


7. Program Request 
а User Response 
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The process that actually occurs during this 
‘operation is that the Non-Active Test Patterns 
specified are moved to another section of core 
storage and the subscriber numbers specified 
are inserted in field B, as shown in Fig. 1. 


Example A 

‘As an example of an Active Test Pattern, let 
us use the previously illustrated Non-Active Test 
Patterns and associate pattern one, POOl, with 
subscribers 2, 4, and 10, pattern two, P002, 
with subscribers 5 and 6, and pattern three, РООЗ, 
with subscriber 11. The console entries are as 
follows: 


TYPEOUT: ENTER SUBSCRIBER 
RESPONSE: 2 

TYPEOUT: NEXT 

RESPONSE: 4 

TYPEOUT: NEXT 

RESPONSE: 10 

TYPEOUT: NEXT 

RESPONSE: END 

TYPEOUT: ENTER DESTINATIONS. 
RESPONSE: Pool 

TYPEOUT: NEXT 

RESPONSE: END 

TYPEOUT: ENTER SUBSCRIBER. 
RESPONSE: 5 

TYPEOUT: NEXT 

RESPONSE: 6 

TYPEOUT: NEXT 

RESPONSE: END 

TYPEOUT: ENTER DESTINATIONS. 
RESPONSE: 2002 

TYPEOUT: NEXT 

RESPONSE: END 

TYPEOUT: ENTER SUBSCRIBER 
RESPONSE: n 

TYPEOUT: NEXT 

RESPONSE: END 

TYPEOUT: ENTER DESTINATIONS. 
RESPONSE: P003 

TYPEOUT: NEXT 

RESPONSE: END 

TYPEOUT: ENTER SUBSCRIBER 
RESPONSE: STP 
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The Active Test Pattern generated in the mem 
ory in Example A, by the communication, would 
look like the following: 


2001 0402001 
0102002 
0302003 
0202004 
0404001 
0104002 
0304003 
0204004 
0412001 
0112002 
0312003 
0212004 
0305005 
0305006 
0305007 
0305010 
0306005 
0306006 
0306007 
0306010 
0413011 
0213012 
0000000 End of Pattern 


The simulator program would then, beginning 
at the top of the Active Test Pattern, proceed 
sequentially down the pattern, generating the 
messages specified. When reaching the bottom, 
the scan is begun at the top again. This process 
is repeated until the end of the test run. 


Subscriber 2 


РОО! Subscriber 4 


2001 Subscriber 10 


РОО? Subscriber 5 


Subscriber 6 


РООЗ Subscriber 11 


MP Simulator Routine 

The function of the Message Processor simu: 
lator routine is to record information under simu- 
lated load conditions, and use it to evaluate 
system performance during the test. 

As soon as a message enters the Message 
Processor, it is assigned a slot in a table. It will 
retain possession of this slot until it has been 
transmitted through the Front End to an ASR 
set and an End-of-Message is received from the 
Front End. When this slot is assigned to the 
message, the data capturing routines are activated 
and continue to record until the slot is returned 
to the available pool. The information gathered 
then written on magnetic tape. Thus, the system 
performance, during the handling of the message 
selected is recorded. The selection of a message 
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to be traced is completely random. The first 
message to enter the system activates the data 
gathering routines. After the table slot correspond: 
ing to that message has been released, the next 
message to enter will reactivate these routines, 
independent of the number or type of messages 
entering the system, in the intervening time. 


Data Recorded During Trace 


The following data is recorded during the 
trace of a message: 


1. Dayclock time of start of trace. 

2. Slot number of message which actuated 
this trace. 

3. Accumulated time from the point at which 
the message being traced entered the Mes. 
sage Processor until it is selected for output. 

4. Accumulated time from the point at which 
the message being traced entered the Mes. 
sage Processor until its slot has been re. 
leased to the available pool. 

5. Idle time during trace. This idle time is 
defined as being the total time that no user 
programs are actively executing. They may 


be in a completely non-active state (not in 

control and not desiring control) or in a 

suspended state (e.g. waiting for the com 

pletion of an Input/Output operation). 

Ratio of idle time to total trace time. 

Input message rate during trace time. 

Number of message slots given out during 

the trace. 

9. Number of message slots returned to the 
active pool during trace. 

10. Number of message slots in use at start of 
trace. 

11. Number of system generated error messages. 
produced during trace. 

12. Various other parameters not meaningful 
to anyone not intimately familiar with the 
system design and operation. 


exe 


SICOM Applications 


This simulator has one significant application. 
It was particularly useful in evaluating Western 
Union's SICOM, the results of this application 
helped gain valuable insight into future system 
performances. 


C. Frey, Jr. is Senior Communications Analyst in P&EO, responsible for the 


modifications to SICOM. 


He joined Western Union in April, 1969, and has been involved in the SICOM 


simulation. Previously, he was 


the Research and Development Department 


of Univac, concerned with systems programming 
Mr. Frey received his B.S. degree in General Science from Penn State University 


in 1966 
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SYSTEM SIZING and Simulation 


in the Design 


of Communication Networks 


with Memory 


by Leonard Stier 


Before implementing а communications network, the network designer must 
resolve a number of basic questions related to system sizing. Given a set of 
communication system requirements, a variety of factors must be considered 
and systematic studies must be carried out to determine the number of switching 
Centers, fix their respective locations and design the intra-system trunking net- 
work. While а comprehensive description of network modeling and optimization 
will not be presented in this article, the nature of the problem and applicable 
approaches will be summarized before proceeding to the main topic of interest 


network simulation. 


System sizing may be approached as a trade 
off between line cost and switching cost. The 
nature of the trade-off can be seen from the fact 
that as the number of switching centers increases. 
at a corresponding increase in switching cost, the 
distance from any customer to the nearest switch- 
ing center is likely to decrease with a correspond. 
ing decrease in line costs. Therefore, access costs 
together with trunking costs are traded-off against 
switching costs, 

‘A communication network, N, consisting of a 
set off n interconnected switching centers is illus- 
trated by the Graph б in Figure 1 having n vertices 
(nodes), Vy, Va», У, and m branches (links), Б, 
ba, ~, ba. Each branch b, is connected between а 
pair of distinct vertices v, and vı. The vertices and 
branches in G correspond to the switching centers. 
and trunks in network N. Associated with each 
branch is a real non-negative number which rep- 
resents the capacity of a corresponding trunk in 
N and a direction in which traffic may flow. Such 
а graph is then called a weighted directed graph. 

Due to the similarity of communications prob- 
lems with transportation problems, some attempts 
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have been made at using the optimization tech- 
niques developed in the latter field. However, as 
shown in Figure 1, formulations for communica- 
tion networks involve a higher order of complexity 
since each node does not simply serve as an origin, 
ог a destination for commodities (messages) but 
is simultaneously an origin, destination or relay 


Figure 1—A Typical Communications Network—Graph G 
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point. Furthermore, even the simpler models must 
have а multi-commodity formulation correspond- 
ing to individual message flows of different priori 
ties between origin-destination pairs. An added 
complication in the design of store-and-forward 
systems arises from the presence of memory 
(Storage) at the nodes. Thus, at any given time the 
flow out of any node may be less, equal or greater 
than the flow into the node. A powerful model 
which takes into account both the time dependent 
nature of the traffic and message priorities has 
been developed by Western Union’. This is a linear 
programming formulation applicable to both ci 
Cuit switching and message switching networks. 
While impractical to apply to large complex sys- 
tems, questions related to optimal routing, node 
storage and trunking capacity requirements of 
smaller systems can be studied. Of greater ap- 
plicability, however, in system sizing have been 
iterative procedures programmed to generate 
hierarchial networks with specified properties rep- 
resentative of those required. 

Once an outline of the structure of the network 
has been obtained, the many design decisions 
subsequently made must be verified. As such, 
simulation has proven an important tool in pro- 
viding additional insight into the operation of com- 
plex systems. 

The General Purpose System Simulator (GPSS) 
has been applied to study ISCS-I subsystems. As 
previously reported, the architecture of the ISCS-I 
message switching element, the Processing Cen- 
ter, has been simulated’. 

In addition, characteristics of a representative 
part of the ISCSA trunking network have been 
studied using an expanded version of GPSS2 
running an a Univac 1108 processor. 


ISCS-| Network 


Structure 

ISCS-I is a hierarchial computer network which 
provides message switching services and inter- 
connection to a set of terminals at various geo- 
graphical locations, shown in Fig. 2. 

The system can be divided into five subsystems: 

1. The Terminal Subsystem—made up of user 
stations. 

2. The Access Subsystem—made up of lines 
and cost-effective equipment—sharing tech- 
niques such as concentrators, way-circuits, 
and multiplexors. 
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3. The Switching Subsystem—consisting of 
Univac 418 Processing Centers (PC) and 
Univac 418 Communication Centers (CC) 
which provide the following functions: ter- 
minal servicing, language and format trans- 
lation, directory look-up and routing, con- 
centration and billing. A fall-back Univac 
418 CPU is present at each site. 

4. The Trunking Subsystem—which provides 
the major arteries of communication trans- 
mission. 

5. The Network Control Subsystem — which 
provides system status monitoring and net- 
work management, for the ISCS message 
Switching system. The Tech Center, which 
monitors the network is located in Mahwah, 
NJ. 


Message Flow 

Messages from TELEX and INFO-COM terminals. 
access the ISCS-I system via low speed lines at the 
CCs. Once accepted by the CC, a particular me: 
sage is routed to a suitably chosen PC (sometimes 
using an intermediate CC) for processing and bil- 
ling. Depending on the multiple address factor, 
опе or more messages are subsequently trans- 
mitted to their corresponding destination point 
CCs for delivery to TELEX, TWX, INFO-COM or 
TMS terminals via low-speed lines, thus compl 
ing a transit of the ISCS-I system. 

All information transmitted on the high-speed 
trunks between the CCs (and on the inter-compu- 
ter synchronizer between CC and PC) is in a block 
format. These blocks are generated in two ways. 
First, as part of the process of transmitting se 
ments of messages between a CC and a PC, blocks 
containing up to 50 text characters are used. 
Secondly, as part of the control process for inter- 
CC transmission, various types of blocks are used 
as part of the block acknowledgement procedure 
оп full-duplex trunks. The latter type of control 
blocks can add a significant overhead to the 
limited inter-CC transmission capability, thereby 
affecting the operation of the system under heavy 
traffic loads. 

The procedures used to control the flow of mes- 
sages between the ISCS-I sites have been simula- 
ted, in order to obtain a measure of the rate at 
which blocks are transmitted between the sites 
and to determine the resulting CC and trunk utili- 
zation. A description of these control procedures 
follows. 
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Figure 2—ISCS Phase | TCCS/INFO-COM Network with Interfaces. 
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ISCS.1 Message Transmission Control 

А simplified account of the procedures used in 
ISCS-I to control the transmission of a message 
from its point of entry into the system to its point 
of delivery is indicated on the flow charts shown 
in Figs. 3, 4. Figure 3 concerns the Message Input; 
Figure 4 illustrates the Message Output. 


Message Input 


A service request generated by a terminal will 
be recognized at the called СС as an Input Re- 
‘quest. After completing an interplay procedure, the 
CC connects the terminal and forms a BID block 
This block consists of 4 SYNC characters, 12 
control characters, up to 50 data characters and 
two characters formed from block parity check 
bits. The bid block is transmitted to the PC and it 
contains the terminal answerback for validation. 
Meanwhile, the CC begins accepting the incoming. 
message from the connected terminal. 

Provided the PC signals message acceptance by 
returning a CONNECT block within 15 seconds, 
the accumulated portions of the message are 
subsequently transmitted to the PC in block for- 
mat. 

The end of the transmission is signalled to the 
PC by means of a special EOT block. Successful 
receipt (in some cases requiring block retrans: 
missions) of all segments of the transmission will 
be signalled to the terminal by an acknowledge- 
ment message sent from the PC to the terminal 
via the CC. The terminal is subsequently discon- 
nected by the CC which signals this action to the. 
PC by means of a DISC-ACK block. 

As a result of the holding time for any connec- 
tion, which is of the order of one minute, exceed- 
ing the message inter-arrival time, there will be 
а number of simultaneous connections active at 
any CC at any point in time. 

The control of the transmission of interleaved 
message blocks on the 2400 baud inter-CC trunks 
is carried out by means of an Acknowledgement 
Waiting Table (AWT). Prior to block transmission, 
the СС enters the Block Sequence Number (BSN) 
into the AWT together with а notation of the time 
of transmission. Blocks received subsequently 
from the other site over the full-duplex trunk are 
checked for a corresponding Acknowledgement 
Block Sequence Number (ACK/BSN). The received 
ACK/BSN will be used to clear the corresponding 
entry in the AWT. However, should the distant CC 
fail to return the ACK/BSN this will be revealed 


‘Autumn 1969 


rare} [tem 


Figure 3—Flow Chart Message Input 
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by a check of the AWT which is made periodically. 
‘The СС will then retransmit all the blocks affected 
by the above transmission error. 


Message Output 


The PC generates an output request, as shown 
in Fig. 4, by transmitting а BID block to а CC. 
In order for answerback validation to be performed 
at the CC, this block contains the answerback of 
the terminal to which the mesage is to be delivered. 
Should the CC be able to complete the connection, 
à CONNECT block is returned to the PC at the 
Completion of the interplay with the terminal. 
Should a network or terminal busy condition be 
encountered, the call will eventually be repeated. 

The message is sent to the CC in block size 
segments at a rate commensurate with the low 
speed line rate of transmission. At the end of 
the transmission and prior to disconnecting the 
terminal, the CC will again trigger the terminal 
answerback. Successful validation and termination 
of the connection is signalled by means of a DISC- 
АСК block sent to the PC. 
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Block Flow Simulation Model 


А typical ISCS-I site consists of a PC and а 
co-located CC. The latter is used to terminate local 
terminals, INFO-COM terminals, TWX and TELEX 
exchanges and TMS reperforator centers. Also, 
2400 baud trunks linking the various other com: 
puter centers shown in Figure 2 are terminated 
at the CC. The PC is linked locally to the front-end 
CC through a fast inter-computer synchronizer. 

А GPSS model or simulation model of an ISCS-1 
PC/CC site has been developed. Previously 
described message transmission control pro- 
Cedures have been incorporated such that the 
model may operate either as a stand-alone site or 
as part of a multi-node network in which the sites 
are linked by up to three high speed trunks. 

The control mechanisms described in the flow 
charts in Figures 3 and 4 will generate the 
following data and control blocks for computer-to- 
‘computer transmission: 
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In GPSS, the structure of the system being 
simulated is described in terms of a block diagram 
drawn with a fixed set of predefined block types. 
Each block type represents a specific action that 
is characteristic of some basic operation that can 
occur in the real system. Connections between 
the blocks of the diagram indicate the sequence 
and combination of the actions that occur. 
Moving through the system being modelled are 
certain basic units called transactions. In our 
system, transactions correspond to messages or 
blocks of data. The sequence of actions occurring 
in the system in real time is reflected in the 
movement of transactions from block to block in 
simulated clock time. Transactions remain at а 
block for an interval of time called the "action 
time.” The action time can be specified by a mean 
time modified by a quantity randomly varying up 
to а maximum value in the range specified for 
the modifier or the action time may be specified 
through the use of a function. Any number of pairs 
of values (x, y) can be used in a table defining the 
function. The table can be interpreted in a con- 
tinuous mode by assuming a linear variation be- 
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tween the points, thereby approximating any 
desired function with straight line segments. The 
table may also represent a step function with 
discrete transitions between the points. 

Associated with the system being simulated 
are certain physical and control elements that 
operate on the transactions and direct their flow 
through the system. These are facilities, storages 
and logic switches. 

A facility can represent any piece of equipment 
which can be seized by a single transaction at a 
time. A storage is an element which can be oc- 
Cupied by many transactions at a time. A logic 
switch is a two-level indicator that records the 
state of some system condition and on which 
certain logical decisions are based. 

Statistics regarding the progress of the simula- 
tion are gathered automatically for the facilities 
and storages. To keep track of queues, the user 
specifies QUEUE blocks which may be used to 
measure average and maximum lengths and, if 
required, the distribution of time spent on the 
queue. Furthermore, a variety of statistics concern- 
ing various system variables may be tabulated by 
means of TABULATE blocks and the contents of 
SAVEX locations, which correspond to locations 
in which information of interest may be entered 
and saved, can be printed out during the course 
of the run. 


GPSS System Outputs 

Operation of a two site PC/CC system has been 
simulated using GPSS 2 in order to study ISCS-1 
network characteristics under various traffic loads. 
Statistics have been obtained for: 

(1) 1/0 trunk utilization. 

(2) 1/0 trunk queues 

(3) Occupancy level in AWT tables 


(4) Average and maximum number of simul. 
taneous call connections carried at each CC 


(8) Percentage of calls which exceed a pre- 
determined threshold for maximum simul- 
taneous connections 


(6) Percent utilization of processors for site-to- 
site communication 


(7) Output message generation rate 
(8) Output message queues 
(9) Speed-of-service 
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А 600 block GPSS2 model for a PC/CC site 
has been generated by using about 450 blocks for 
the CC and 150 blocks for the PC. The statistics 
shown in Fig. 5 for a two site 1200 block system 
represent the state of the system after 23 minutes. 
of simulated operation at a message input rate of 
0.5 msg/sec per site. Exponential message size 
and appropriate message routing functions were 
used. 

Sample formats in which the results of a simu 
lation are presented are given in Fig. 5 and Fig. 6 
for one representative run (A). As the simulation 
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Figure 6—Printout of the Statistical Output for 
the GPSS Simulation 


WESTERN UNION TECHNICAL REVIEW 


progresses, cumulative results, similar to those 
shown in Fig. 5 and Fig. 6 are printed out at 
specific time intervals to establish trends in the 
behavior of the system. From these data, graphs 
for Run A were plotted in Fig. 7 and Fig. 8 and 
graphs for Run B were plotted in Fig. 9 and 
Fig. 10. These graphs were used in further analy- 
sis to determine the duration of the simulation 
required to reach steady state conditions. Fig. 9 
and Fig. 10 are included here to illustrate the 


manner in which changes in the model can be 
made with the simulation repeated (Run B) in 
order to study specific aspects of system behavior. 
Figure 9 and Figure 10 show the contrasting 
effects on the utilization of system elements 
resulting from the use of certain controls which 
limit the number of active output connections 
(slots) at the PC. For run (B) all other conditions 
present in run (A) were left unchanged. 
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Figure 7—input Processing Time for Run A 
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Figure 8—Facilty Utilization for Run A 
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Figure 9—input Processing Time for Run B. 


As is apparent from Figure 10, the utilization of 
the high-speed lines reached a steady state of 
about 58 percent and the CC reached 69 percent 
for this run. This is in contrast with Figure 8 
where the 80 output slot PC limit was not in effect. 
As a result, much higher traffic flows were estab- 
lished between the sites resulting in line utiliza- 
tions in excess of 78 percent coupled with a 
corresponding decrease in storage requirements 
at the sites. 


Furthermore, as may have been expected of a 
control affecting output, the above logic change 
had little effect on the speed with which the CC. 
to PC message input transit occurred. This was 
shown in Figure 7 and Figure 9. 
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Figure 10— Facility Utilization for Run В 


Further studies have been made for a range of 
high speed line capacities and the effects resulting 
from loss of trunks have been analyzed by chang- 
ing individual blocks as appropriate and re-run- 
ning the simulation. 


‘Summary 

Design techniques applicable to system sizing 
have been described in this article. The use of 
various analytic models which are applicable to 
the design of computer networks has been in- 
cluded. Simulation has been introduced here as 
а tool used to verify design decisions connected 
with the implementation of complex systems such 
as 15654. 
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Figure 10—Harvey Mayerowitz Discusses the 
Program with the Author 
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Estimating Storage Requirements 
ina 
Store-and-Forward Switching System 


by MILTON MORRISON and ANNE PANICCIA 


Statement of the Problem 


Опе of the problems in a real or hypothetical 
store-and-forward computer type message switch 
ing system accessed by means of half-duplex 
remote terminals, is to determine its storage re- 
quirements. Ignoring, for the moment, multiple 
address or group code type traffic, every message 
which enters the system on one terminal creates 
another message which leaves the system at some 
other terminal unless prevented from doing so 
because of a system failure. A half-duplex line сап 
transmit messages travelling in both directions, 
but only in one direction at a time. Therefore, 
a terminal is inputting a message to the system, 
ог accepting а message from the system, any 
Other message which must be output on that 
terminal must wait on queue, until the destina- 
tion terminal is free. This queue is referred to as 
the "output message queue." It is the purpose of 
this article to describe the time dependent size 
of this output queue, so that adequate computer 
storage allocations can be provided. 

It is also possible that messages may be wait- 
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ing to be input at a terminal, similar to people 
standing in line waiting to use the terminal. These 
messages wait in what is referred to as an "input 
queue." This input queue is not a physical part of 
the computer system and makes no storage de 
mands on it. Therefore, it needs no physical con- 
sideration in system design, but it must be con- 
sidered in the design for its effect on the system's 
output queuing condition. 

Input traffic units (messages) arrive at the ter- 
minal at a variable time rate. The hypothetical 
system gives input priority over output; i.e., if a 
message is waiting to be output at a particular ter- 
minal, the system will suppress output so that any 
and all messages on queue for input can be serv. 
iced. Thus, if a second message is to be input, 
then the output message (waiting on queue) will 
again have to wait until the message is through; 
this condition continues until that point in time 
when the input queue is zero. Then output can 
begin and will not be interrupted until that mes- 
sage has been delivered to the terminal 
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Since all this occurs at а single terminal, storage 
must be provided, within the computer system, for 
the output messages of the entire set of terminals 
supported by the computer system. Naturally, dur- 
ing the daytime hours, the amount of occupied 
storage fluctuates, as the system traffic load rises 
and falls. It is a problem to determine the amount 
of computer system storage which should be 
supplied to accommodate the queue of output 
messages, with real assurance that the recom- 
mended storage will be adequate. Since the queue 
size, at any instant, is a random variable, the 
problem must be examined on a probabilistic 

is. If attention is fixed on any one instant of 
the number of messages on the output 
at that instant, is the sum of the numbers 
of messages on all individual output queues for the 
terminals associated with that computer. This sum 
will vary during that portion of the day di 
which messages enter and leave the system. The 
basic problem is to determine a value so that the 
sum exceeding this value is 
lected small number. 

Before moving to the mathematical description 
of the problem statement, one more very critical 
assumption must be made. It will be assumed 
that every terminal serviced by 
periences the same diurnal var 
That is, consider an arbitrary time interval (t. ta): 
the percentage of a particular terminal's total dai 
input traffic is the same for all terminals during 
this time interval (neglecting quantization errors). 

These statements will be more meaningful to 
the reader when contemplated in connection with 
the traffic profile. 


Typical Daily Traffic Profile 


In order to solve numerically for the output 
queueing situations, one must first review the 
manner in which traffic arrives at a terminal during 
the day. A typical traffic profile has been selected 
for application in our queueing analytics. 

An input traffic profile of messages actually 
arriving at Western Union's ISCS Phase | systems 
in New York and Chicago in early 1969, is shown 
in Figure 1. Each bar represents that portion of 
the total daily input traffic which has arrived in that 
time interval. Between 0900 and 0930, for exam: 
ple, Figure 1 reads 2.9 percent. This means that а 
terminal received 2.9 percent of its total daily 
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input traffic in that time interval, Notice that 
this interpretation does not depend on the actual 
volume’ the terminal handled: whether a terminal 
is highly utilized or barely utilized, it still handles 
2.9 percent of its daily input traffic in this half 
hour. This same traffic profile therefore applies 
to all terminals and thus to the entire system. 

‘Summing all the bars, we observe that at time 
2100, the system has received 98.1 percent of 
its total daily input. If the graph were extended 
to a 24-hour day, the sum would accrue to 100%. 

The total input traffic 
individual terminals. This apportionment can be 
varied, but for purposes of easy accounting and 
description, it will be assumed that the terminals 
are numbered 1, 2, 3, ..., Н, and the amount 
of input received from each terminal is monoto- 
nically increasing with the terminal number. A 
simplified model would make that increase pro 
portional to the terminal LD. (Identification), 
such that, if we let the total traffic received at the 
j* terminal be C-j, where: 

C = constant 

= number of terminals 

total input traffic rate being received by 


all terminals 
2 Cj =1 а) 
and 
(2) 
From Equations (1) and (2), it follows that 
C = 2l/H(H +1) (8) 


Thus, input traffic rate being received at the j^ 
terminal would be equal to 21/H (H + 1). This ex- 
pression applies even if | were the traffic received 
up to any time t, rather than an expression of 
traffic rate. 
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Definitions and Assumptions 

The following definitions and assumptions are 
necessary for the understanding of these deriva- 
tions. In all definitions, the subscript j may be 
dropped if no ambiguity results. 


(а) The mean rate (msg/unit time) at which 
messages arrive at the j* terminal (line) 
for input to the system is designated A.(t). 
It will also be referred to as the mean in- 
put rate. The mean input rate is a function 
of time, 

(b) An analogous definition holds for the output 
message rate, Ac, (t). The subscripts | and O 
оп any symbol refer to input and output 
respectively. 

(с) The mean total rate (in msg/unit time) 
at which messages arrive at the j* terminal 
(line) for input or output is designated A, (t), 
and will be referred to as the mean total 
traffic rate; A(0)—A (04-90 

(d) The probability that a message currently 
being processed will complete its input or 
‘output processing during a small time in- 
terval, At, is р (At) where р is assumed 
to be constant and in this analysi 
same constant for all terminals (lines). 

(e) The probability that a message will present 
itself for service at the j* terminal (either 
input or output) in a small time interval, At, 
is DK AO 

(O After а period of time, № (t) declines to 
zero for all j. 

(2) A message is said to be on queue whenever 
it is either being processed by the terminal 
or waiting to be processed. 

(h) All queues are zero at t = 0. 

(i) The aggregate number of messages on ail 
Output queues and on all input queues 
may be taken as the sums of all the indi- 
vidual output or input queues. 

(j) The mean number on queue at the j* 
terminal is Mit) and the variance of the 
number on queue is V(t). The mean and 
variance of the aggregate are designated 
МО) and V(t) respectively. 

(W The number of terminals (lines) involved 
in the message switching system is H. 
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Single Terminal 

Consider a single terminal. If all of the above 
statements hold and messages arrive at the term- 
inal at a lesser mean rate than the mean rate at 
which they are processed out, the typical queueing 
situation exists. Theory applicable to such queues 
is available, and, in particular the mean and 
variance of the number on queue, have been 
derived for those queueing systems having the 
following properties: 

1) There is one channel or terminal. 

2) Time between arrivals has an exponential 


distribution with the mean =; A is the ar- 


x 
rival rate and is a constant (ie, not а 
function of time) over sufficiently short 
intervals of time. 


3) Processing time is exponentially distributed 
with mean — 1; и is the processing rate 
and is а constant (1е., not a function of 


time). 
4) Messages are processed in order of arrival. 
5) < 
6) The terminal is in a steady state condition; 


that is, it is no longer affected by the con- 
ditions which existed at the initiation of 
operation. 


Mathematical Model. 


Let p equal the proportion of time a terminal is 
utilized. p is equal to mean processing time 
rival time. Hence, p 


5 it is also called the traffic intensity. 


Ta 
It is shown in References 1 and 2 that under the 
above circumstances the mean number on queue is 


¥ = 7 a 


and the variance is 
v= qty = Mat) (5) 


If A>, then p>1, and the above formulae по 
longer hold, since p is no longer the occupancy of 
the line; but it can still be regarded as the traffic 
intensity. It is noted that when p<1, there are 
periods during which no messages are being 
the terminal has open time. If, 


197 


however, p>1, the terminal will, in general, be 
Processing continuously; and furthermore, there 
will be an increase of the queue size due to the 
fact that messages are arriving for service at а 
greater rate than they can be handled. 

Basically, then, two modes of operation must 
be recognized: 1) the queueing mode, when Au. 
and the terminal has open periods; and 2) the 
fully utilized mode, when А> и, and the terminal 
is assumed to be processing full time. 

When a terminal is in the queueing mode, there 
is по problem in determining the mean and 
variance of the number on queue. The formulae 
stated above, for mean and variance respectively 
are applicable. 

It will also be necessary to obtain the mean and 
variance of the number of messages on queue, 
when the terminal is in the fully utilized mode, In 
this mode, the time between the completion of 
the processing of messages has an exponental 
distribution. 

Let x — number of messages which arri 
(t, ta) during which interval the system 
the fully utilized mode. Let y = the number of 
messages which are processed during this time. 
Both x and y have Poisson distributions with 
means equal to ^ (tj—t,) and и (1—4) respec- 
tively. Suppose the number of messages on queue 
at the inception of the fully utilized mode is z 
and its expected value is b. Then the expected 
value of the number of messages on queue at 
tı is the expected value of z + x — y. 
Symbolically: 

E (z +x — y) = b + E(x) — Е(у). 

Assuming z, x, and y are independent, 

V@+x—y)=V@) + Vo) + VO). 

Since the variance of a Poisson distributed variate 
is equal to the mean, 

V (2+x=y) = VQ) + EG) ЕО). 


Transfer Between Modes 


When p is close to, but less than unity, the 
queueing mode formula for the mean gives very 
large values. For example, when p = .99, M = 


Intuitively, one does not imme- 


distely anticipate thet the mean (i.e., expected) 
lal which is processing messages 
idly as it is receiving them should 
necessarily be high. 


The explanation lies in the nature of the ex- 
pected value as a characterization of a probability 
distribution, and in the fact that the formula 
used for the mean is for a steady state condition 
which cannot be achieved in a short period of 
time. (The same environment applies to the 
formula for the variance.) 

If the queueing mode formula for the mean 
gives a large value, it must satisfy a test which 
determines whether or not it has had enough time 
to reach that value. If it has not, then the value 
given by the formula must be rejected and replaced 
by a number calculated by a method which takes 
into account the fact that steady state conditions. 
could not have been achieved in the available time. 

This may best be illustrated with a numerical 
example. In Table I, the traffic statistics for 7 time 
intervals, 30 minutes each, on a typical terminal 
are tabulated. 

Column 2 of Table | lists the mean number of 
messages arriving for processing (both input and 
output) at a hypothetical terminal during succes. 
sive 30-minute intervals. For this terminal, the 


mean message processing time 
utes/msg. The message arri A, are 
equivalent to the numbers in column 2 divided 
by 30. 


Column 4 is the traffic intensity 


Column 5 is the mean number of messages in 
queue (M), calculated from the queueing formula 
in equation (4). 


A 


Column 7 is the variance computed from the 
queueing formula in equation (5). 
Columns 8 and 9 are the means and variances, 
finally computed. These are the essential charac: 
teristics of the traffic pattern. 

їп the 2nd, 3rd and 4th interval it is observed 
that the difference in volume between two time 
intervals shown in Col, (3) exceeds the difference 
in mean queue estimate (M) between two time 
intervals, as shown in Col, (6). From the 4th to 
the Sth interval, the converse is true (9.8<12,91), 
This complication is explained as follows: 

From the 4th to the 5th interval, the rate in- 
creased from 20.3. msg/min, to 20-1 

30 30. 

The increase in rate is 28 msg./min, Thi 


msg./min. 


in: 


WESTERN UNION TECHNICAL REVIEW 


9982 sez gzet n we 
r6 

$2602 962t зот gee чө 
эг 

озу тп vec гәтт эє6' Tos "s 
1621 86 

59% ил 59% ил 169. eoz чу 

TET zu 

ss Set tss 6" esz v6 pig 
эг zv 

1 Cag uz eu zst 6v puz 
г zy 

zo zzo ezo Ezzo' 3120 1 st 

A и eoueueA |әјешц3 anenğ| anandur | Aysuejuy sueaw |  soBessow емеш 
ueaw uoomiog saBessoy јо эше usameg ю 911559215 
eousseyig | soquiny ueow eouasepiQ | ssaquiny uean 
(6) [C] [^] ө) ©) o (e e (г 
13181. 


199 


crease in rate operating over 30 minutes would 
introduce into the system an additional 9.8 mes- 
sages on the average, over and beyond that entered 
by the previous rate which provided a mean queue 
of 1.71. Hence, in the time interval of 30 minutes 
the mean queue should not have increased more 
than 9.8 and indeed would probably have increased 
by less. 

The formula dictates that the mean has in- 
creased by 12.91, but this is improbable. The 
apparent contradiction is explained by the fact 
that the formula is applicable to steady state con- 
ditions which could not have been achieved in 
the 30-minute period. Thus, we reject the value 
given by the formula and take the mean queue 
equal to 1.71 + 9.8 = 11.51. The terminal is still 
in the queueing mode and the variance is com 
puted from: 


V=M(L+M) = (11.51) (12.51) = 144 
which appears in row 5 of Column 9. 

In the sixth time interval, p>1 and the terminal 
passes into the fully utilized mode, During the 
sixth time interval, it is seen from Column 2 
that 33,6 messages entered for processing. Since 
in this period it is assumed that the terminal is 


fully utilized, C39.) = 32.15 messages were pro- 
cessed (on tl ge). Thus, 33.6 — 32.1 
1.45 messages were added to the queue which 
existed at the beginning of the sixth time interval. 
Hence, the mean queue at the end of the 6th time 
interval is 11.51 + 1.45 2.96 the value for 
M, listed in Column 8. 

Using Viz + x — у) = V (2) + Е (х) + Е (у), 
the variance of the queue size at the end of the 
sixth interval is 144 + 33.6 +32.15 = 209.75. 

In the interval 7, the terminal is still in the 
fully utilized mode so that the mean is 12.96 
+ (42.7 — 32.15) = 23.51 and the variance is 
144 + (33.6 + 42.7) + 2(32.15) = 284.6. 

The above example displays the logic for the 
computation of an individual terminal's time de- 
pendent queue. The queue starts at zero and builds 
up in the queuing mode (as traffic rises) until it is 
sensed that the time rate of change of the mean 
queue given by the queuing formulation exceeds 
the volume rate of change. At this point the mean 
queue computation switches to an accumulation 
of excess message rate over and above that which 
was operative in the queuing mode. The situation 
reverses itself under conditions of decreased 


traffic, except that all queues are allowed to de- 
plete before switching to the kueing mode form- 
ulation. 


‘Terminal Queues and Message Storage 
Requirements 

The random variable of particular interest is the 
total number of messages on queue (as a function 
of time). A theorem of mathematical statistics, 
the central limit theorem, states roughly that the 
probability distribution of a sum of n independent 
random variables approaches the normal distri- 
bution as n> =, with mean equal to the sum of 
the means and variance equal to the sum of the 
variances. 

In our system the n independent variables are 
the queues at the n terminals. It follows that the 
total number of messages on queue at any time, 
t, can be regarded as normally distributed and 


мо = Xo 0 
vw = Evi ® 


The mathematical model is required to find the 
number, К, such that the probability of a normally 
distributed variate with mean M(t) and variance 
V(t), exceeding K is e, where e is a small positive 
number. 

Thus far, it has been tacitly assumed that all 
the messages on both input and output queues 
would have to be stored. However, as noted pre- 
viously, only output messages require computer 
storage; the input messages queue outside of the 
system. To handle this situation, we first compute 
the mean and variance of the total queue for a 
terminal [i.e., M, (t) and V, (t)] using the total 
message rate 


Af) = 3f) + A(t) (9) 


This overestimates the required computer stor- 
‘age by the amount queued on the input side. Then, 
же compute the mean and variance of the input 
queue using only the input message rate A (Ù 
which ignores any interference on input due to 
‘output messages. Since the priority structure on 
Our system prevents messages on output from 
interfering with input unless the message to be 
output is already in the course of output trans- 
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mission, ме are confident that the above computa- 
tion underestimates the average input queue but 
by an amount less than one message per line 
Thus, we take a mildly pessimistic approach and 
‘subtract the mean input queue from the total 
queue to estimate our output queue. That is, with 
an error less than one message unit per line or 
terminal, the following equation is true: 


Mot) = м) — Mat) (10) 


With regard to the variance, the situation is 
not quite as simple. However, we note that the 
covariance between the input and output queues 
will tend to be positive (more on input implies 
more on output). This being true, we can compute 
Vo, (=V; (t)—Vi, (0 and be confident that the 
estimate of the output queue variance is 
conservative. 


Ап Example 
To illustrate the method of obtaining message 
storage requirements from terminal queues, let us 
assume the following data: 
1) 20 terminals 
2) 56 sec = .933 minutes, mean processing 
ime for both input and output messages 
3) Input message rate equals output message. 
rate for all terminals. 
4) 6000 messages total input 
5) The traffic profile, derives from Figure 1 
with some adjustments to make the total 
percentage equal to 100. This is tabulated 


in Table 1. 
6) Daily input traffic at the jth terminal is 
given by 
2j(6000) _ 
(201) = 2857 ш 
where Fhe: 


It is required to obtain the amount of storage 
required so that, during that period of the day at 
which the storage is most heavily utilized, the 
probability that a message will find no storage 
available is .001. 
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TABLE 


Successive Intervals 


Total Traffic 
(percent) 
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A program was written to effect the mathe 
matical model described in this example. The 
partial printout of this program, shown in Fig. 2, 
lists the mean and standard deviation of the total 
number on queue at all terminals for the entire 
day. The columns of particular interest are those 
labeled "FINAL MEAN" and "STANDARD DEVIA- 
TION.” Note that the largest mean occurs during 
the 20th time interval at the end of which interval 
the mean is 2500.055 and the standard deviation 
is 122.346. From tables of the normal distribution, 
it is noted that the probability that a normally dis. 
tributed variate is greater than the mean plus 3.09 
standard deviations is .001. Hence, if storage is 
provided for 2500 + 3.09 (122.3) — 2500 +378 

2878 messages, the requirements for providing 
sufficient storage will have been satisfied, Thus, 
we are confident that we shall not need a storage 
greater than 2878 messages. 


Acknowledgement 


Further Application 


While this example was based on the assump: 
tion that all terminals followed the same traffic 
profile, this need not be always true for the method 
to be valid. 

In fact, all terminals could have different traf. 
fic profiles, message processing rates, and output 
input ratios. The subscribers need not be termi. 
nals, but could be lines leading to other message 
producing and/or receiving sources. As long as 
it is possible to compute the mean and variance of 
the queue of messages related to the terminal or 
Subsystem, the model and techniques described 
above are applicable 
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Milton Morrison, Senior Staff Analyst 
in Systems Design and Analysi 
PAEO, is responsible for the proba. 
bilistic aspects of communications 
systems. design. 


Mr. Morrison was associated with 
Stevens institute for 11 years as 
teacher of mathematics and statisti. 
to the Davidson Laboratory; he 
Came to Western Union after ten 
years with ITT, 


He holds a BA degree from Mont 
Clair State College and an MA from 
Columbia University, and is a mem 
ber of the American Statistical Asso- 
ciation, Institute of Mathematical 
Statistics, and Operations Research 
Society of America; he was a dele 
gate to the Fifth International Tele. 
traffic Congress. His previous 
Publications on applications of prob. 
ability and statistics have appeared 
in Biometrics, Technometrics, IEEE 
Transactions on Military Electronics 
and other journals. 
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TIME FINAL STANDARD 
INTERVAL MEAN DEVIATION 
1 194 764 
2 1734 2327 
3 4378 3.824 
4 51.510 27.121 
5 137.818 40.451 
6 243.069 49.633 
7 449.554 62.743 
8 645.489 69.382 
9 845.663 76.792 
10 958.609 79.080 
n 1004.672 79.507 
12 1046.272 83.702 
13 1137.406 88.479 
14 1278.838 94.053 
15 1503.377 101.478 
16 1737.788 107.281 
17 1979.305 113,003 
18 2258.264 119.588 
19 2463.162 123.207 
20 2500.055 122.346 
21 2451.678 123.283 
22 2231.672 115.985 
23 2040.939 117.649 
24 1834.849 113.441 


Figure 2—Partial Printout for the Mathematical Model 
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Anne Paniccia, Junior Systems Analyst in Systems 
Design & Analysis, P&EO, has previously been a trainee 
at Western Union and is currently working on her de 
gree in Master of Science at Courant Institute of Mathe. 
matical Sciences/New York University. The subject of 
her Thesis: Queuing theory in a time-sharing environ 
ment with priority. 


Miss Paniccia joined Western Union in 1968 and since 
then has been involved in the comparative evaluation 
of compiler and assembler languages available on the 
Univac 1108, and in the modelling and implementa- 
tion of systems simulations conducted in GPSS. 


TPUT— 


A SOFTWARE DIAGNOSTIC 
PROGRAM FOR ISCS 


Бу R. D. O'MEARA 


A diagnostic, is an aid in diagnosis, simply stated. In computer programming, 


^ This 


inostic is a special purpose program designed to test and evaluate a. 
‘given system" can vary from the relatively simple (a light bulb) 
very complex (a multicomputer system). Of cours 


‘the more complex the 


system the more care must be used in designing the diagnostic. Western Union 
has one such complex system called ISCS, for which TPUT was designed and 
found very useful in measuring the performance this ISCS service, 


As part of their modernization plan, Western 
Union is automating its record communication 
services. One of these services is the ISCS (Infor: 
mation Shared Communication Service), a shared, 
store-and-forward, message-switching system, that 
will eventually service many of the terminals such 
аз TMS, TLS, TWX, and ICS [Telegram Message 
Service, Telecommunications, Teletypewriter, and 
Information Communication Service (private)]. 
ISCS is currently in its Phase | state which con. 
sists of three main segments: 
(1) the terminals, 
(2) the communication lines (COM LINES), 
and 
(3) the computer complex where all the 
message routing is performed. 


Computer Complex 

The ISCS computer complex, in Phase |, is 
actually four separate, linked computer centers. 
Communication line terminals and two Univac 
418 computers comprise the main equipment at 
each computer center. The communication line 
terminals or termination (CLT) units are con 
tained in large arrays called a multiplexer, MUX. 
Several of these MUXs and the hundreds of lines 
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they terminate form the interface between the 
‘communication lines and the Communication Cen. 
ter (СС) computer. The electronic signals put on 
the "сот" lines by use of the terminals are in- 
terpreted by the MUX for the CC computer. This 
linkage allows a user to type a character on his 
terminal device and have the computer receive it 
in an understandable format that can be pro 
cessed by the various programs (software) in the 
two computers at each center or site. The main 
function of the CC computer is to collect and con 
centrate the characters it receives and to send the 
accumulations to the “second” 418 computer, the 
Processing Center (PC). While the CC deals in 
characters, the PC works with accumulations of 
characters, defined as messages. The store-and 
forward characteristic of ISCS is inherent in the 
design of the PC software. A message is received 
and accepted: then it can be stored on some large 
storage device for later processing and delivery. 
Аз the message load increases, the time to deliver 
each message lengthens a little; until all of the 
“com” lines are being used and no new traffic 
can start. This point is the design maximum ге. 
sponse time and is usually quoted to the customers 
as the time required to deliver an average message 
or “speed of service” 
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How ISCS Works 


To a subscriber, ISCS works as follows: A mes- 
sage is sent from his terminal over the lines into 
the computer. The computer analyzes the desti- 
nation(s), performs any code or speed conversion 
required, creates records for billing and retrieval, 
and delivers the message over the lines to the cor- 
rect terminal. The complexity arises from the han- 
dling of hundreds of messages in parallel; some 
with errors, most without errors and verifying that 
all requests were satisfied. 

The simultaneous mixing of large numbers of 
messages in a computer system that temporarily 
might fail, requires a highly reliable message- 
accounting system to insure complete delivery of 
all accepted messages. 

As the above illustrates, ISCS is a difficult sys- 
tem to evaluate because there are several major 
subsystems that obviously must be verified before 
they can be tested with other sections of ISCS. The 
testing of a system like the computer section of 
ISCS is almost as complex as the ISCS itself. A 
growing system like ISCS needs to be continuously 
tested and evaluated. 


Development of the Diagnostic 


In developing and designing diagnostics, the 
“what the system does” is much more important 
than “how it does it." Therefore, designing a diag. 
nostic for the computer section of ISCS requires a 
very clear idea of what functions it performs rather 
than how. 


After а thorough study of the actual working 
of the ISCS system, a special diagnostic program 
(called TPUT (а mnemonic for Through Put) was 
developed. This program sends and receives mes- 
sages to and from ISCS just as the customers do. 
By concentrating on the "'simulation" or replace: 
ment of the outside environment of the computer 
section of ISCS, the TPUT program aids in the де. 
tection of errors that manifest themselves di 
the processing of the TPUT traffic. 

The reasoning behind using а message simula- 
tion philosophy for TPUT follows from the inherent 
design of ISCS, which is a message-switching sys- 
tem. Even though TPUT does not point out the 
trouble areas, its use allows ISCS programmers to 
reproduce the problem repeatedly until the prob 
lem is isolated and solved. 


‘Autumn 1969 


TPUT 


TPUT is a self-contained program located in the 
Phase 1 CC computer, in a memory area normally 
used for character buffering. TPUT requires that a 
Univac FH—30 magnetic drum unit be attached 
permanently to the CC. TPUT is a "hitch-hiker" 
type program designed to be invisible to the reg: 
ular CC programs. However, since TPUT occupies 
memory locations and consumes processing time 
normally used by the CC program, TPUT limits the 
environment of the CC. At high traffic levels, this 
is important. To accomplish its objective of gen- 
erating traffic for the Phase | computer center, 
TPUT must simulate messages coming to the com 
puter. This simulation requires the TPUT Program 
to monitor all control and data transmissions be- 
tween the CC software and the Input/Output (1/0) 
channels (which are directly connected to the 
MUX's). When TPUT detects activity that normally 
would go to a specific COM line (via an 1/O chan 
nel to а MUX to а CLT), it compares the line num: 
ber to a table of line numbers it wishes to replace 
(simulate). If a match is found, the information 
from the CC is made available to TPUT rather than 
allowed to be transmitted to the "COM" line, In 
а similar manner, TPUT gives information to the CC 
as an 1/0 channel (driven by а COM line) would. 
Therefore, TPUT has simulated the interface be- 
tween the CC and the outside world for those lines 
chosen; in fact no actual MUX or "СОМ" line is 
needed. 


TPUT Messages 

The remaining task of TPUT is, then, to send 
and receive messages over the simulated COM 
lines. These TPUT generated messages take ad. 
vantage of the unimportance of message contents 
in a test atmosphere; therefore, only routing infor- 
mation is really required. These routing lines are 
the only information that need be prepared to 
enable the operation of TPUT. A unique feature of 
TPUT is its ability to generate thousands of dif 
ferent messages, from a few choice groups of rout: 
ing lines representing the geographical nodes of 
the ISCS. As ТРТ receives back the messages it 
has sent, the time difference is noted. In this way 
TPUT fulfills its design of measuring the "through 
put" time of the ISCS system. 
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Applications for TPUT 


ТРИТ was designed to fill the gap between test 
message capability and test message desirability 
for handling large loads. It is designed to run all 
the terminals in a simulation mode and hence sup. 
ply а background of traffic against which the spe- 
cific test messages may be evaluated. Therefore, 
а test effort can be devoted to verifying a problem 
area, instead of trying to load the system in order 
to reproduce the problem. 

TPUT has many other applications as a diag 
nostic. It can input a standard series of messages 
зо that the ISCS computer system сап be evalu- 
ated, by its performance in handling this standard 
load. TPUT can also drive the computer system 
to its traffic-handling limit, and hence determine 
for management evaluation how much customer 
service can be provided. Since the ISCS computer 
complex is made up of several separate but linked 
computer centers, with geographically dependent 
data relating to specific terminals, TPUT can run 
these computer centers at a test laboratory com: 
puter center prior to their installation or cut-over 


at the sites. This inherent simulation philosophy 
basic to TPUT allows any terminal type to be sim: 
ulated. In addition, the traffic generated by the 
TPUT program can be varied a great deal for any 
particular test desired, 

While TPUT is designed to be a one man op: 
erable system, it has the capability for automating 
many ISCS tests. Some of the possibilities for 
automation are as follows: automatic data base 
verification for specific computer center sites. 
automatic production of billing test cases for im. 
provement of the billing process of ISCS, and the 
automation of test procedures previously used by 
duplicating their non-standard messages by means 
of simulation rather than actual transmission. This 
last possibility involves verifying the delivery of 
the rejection notices of these special cases. 


Conclusion 

TPUT has been a significant addition to Western 
Union's testing capability. TPUT allows us to test 
а shared system, such as ISCS, without inter 
ference to the customer and at the same time 
measure its capability in handling high traffic load. 


R. D. O'Meara, Systems Analyst in 
the Planning and Engineering Op- 

ion, is responsible for the test 
ing and design of ISCS, computer 
concepts. 


Me came to Western Union in 
September 1968, Previously, he was 
involved in simulating the Apollo 
fight to the moon in an automated 
flight simulator. He was also in 
volved in application programming 
for Apollo. 


Mr. O'Meara received his B.S. de- 
gree in Physics from the University 
of Ilinois in 1965. 
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SYSTEMS DESIGN— Р 
A CONTINUAL 
ANALYSIS PROCESS Е 


‘The articles in this issue emphasize the spec id more sophisticated tools 
and techniques necessary to the design and implementation of the complex computer- 
controlled communication systems now being implemented by Western Union. New 
techniques have become necessary because of the difficulties faced by the designers of 
such systems. One such difficulty is the fact that the resources of such systems are fixed, 
while the demands or constraints made upon them are random. The designed systen 
must meet various constraints such as: cost effectiveness, reliability, and service flex 
bility 


In order to meet this challenge the Systems Analyst devises analytical and simu 
lation models, empirical measurement tools, and various effectiveness measurem, 
techniques. Although such techniques are often eri 

they do not constitute the design process itself. Therefore th 
be careful not to lose sight of the primary design objectives in the design 

he risk a project inadequacy induced by replacing primary goals by secondary 
or techniques. 


One major task of technical projec и is the “continual evaluation” 
of the objective, tools, and techniques so that the design process moves forward toward 
its objective. Although easily stated, the task itself is not easily carried out, because 
the design process for such complex systems is not truly deterministic, The general 
approach consists of 


* Defining the primary goals red in the final product. 


* Defining the constraints under u 
operate. 


ich the product must be developed or 


® Decomposing the total design problem into sub-proble 


which hopefully 
сап be optimized (locally) and definitely can be managed. 


® Penetrating the design to a particular depth, re-composing the parts and 
extrapolating the results to the end product so that it can be measured 
against the design objectives and constraints, This, then, gives a “foasib 
path through the design process 


© Adjusting the design elements to pr 


ide а better end result, continuing the 
design penetration and iter 


The major problems fe ign process are those dealing with the 
composition (“synthesis”) of the parts and extrapolation to the end product, a deli- 
cate matter at best. The recom position must adequately consider the interactions among 
the parts of the system and the resultant nonlinearities in the recomposition. It is 
usually in meeting these difficult issues that the most sophisticated of system models 
and measurement tools get defined and implemented in order to provide definitive 
check points on the design status. Often these tools and techniques are of sufficient 
generality and utility to provide guidance to future designers. 


However, in the final analysis it is the engineering judgment "talent" — of the 
managers and individual contributors which allows the design process to work, With- 
out this judgment, the design approach generally foils. ® & в а в ww m m m 
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Supermarket Chain 
Uses 
Western Union Desk-Fax 


The week-end prior to Thanksgiving Day, the big shopping week 
of the year, will see the inauguration of a test program conducted 
by Western Union and the A. & P. Food Stores at 11 supermarkets 
along the Eastern seaboard, 


The test will determine the practicability of providing telegraph 
acceptance services in supermarkets. If successful, A. & P. envi- 
sions the addition of telegraph services to the growing list of 
services now being provided in their markets aeross the country. 


Western Union's objective is to make their services more acces- 
sible to the publie, especially in areas remote from telegraph offices. 


Desk-Fax tie lines have been installed at the test stores. Desk- 
Fax units will provide an A & P agent with instant access to a 
Western Union office without the necessity for manual transmis- 
sion of the message. 


Е. J. McQuillan, Director 


Service Coverage 
Public Office Operation 


WESTERN UNION TECHNICAL REVIEW 


